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Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. This memo does not specify an Internet standard of any 
kind. Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Abstract 


There is a need for a framework wherein the infrastructural and 
service related information about communication networks can be made 
accessible from all places and at all times in a reasonably efficient 
manner and with reasonable accuracy. This document presents a model 
in which a communication network with all its related details and 
descriptions can be represented in the X.500 Directory. Schemas of 
objects and their attributes which may be used for this purpose are 
presented. The model envisages physical objects and several logical 
abstractions of the physical objects. 
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1. Introduction 


The rapid and widespread use of computer networking has highlighted 
the importance of holding and servicing information about the 
networking infrastructure itself. The growing and active interest in 
network management, which has concentrated mainly in the areas of 
fault and performance management on a local scale, is severely 
constrained by the lack of any organized pool of information about 
the network infrastructure itself. Some attempts have been made, on a 
piecemeal basis, to provide a larger view of some particular aspect 
of the network (WHOIS, DNS, .. in the case of the Internet; [1], 

[2]). But to date, little or no effort has been made in setting up 
the infrastructural framework, for such an information pool. In this 
work we explore the possibility of setting up a framework to hold and 
serve the infrastructural information of a network. 


2. Infrastructural information requirements 


Network operation and management requires information about the 
structure of the network, the nodes, links and their properties. 
Further, with current networks extending literally beyond bounds, the 
scope of the information covers networks beyond the span of local 
domain of authority or administration. When the Network was 
relatively small and simple the map was already known to the 
knowledgable network administrator. Based on this knowledge the 
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course of the packets to different destinations would be charted. But 
presently the size of the Network is already beyond such usages. The 
current growth of the Network is near explosive. This is giving rise 
to the urgent necessity of having infrastructural and service related 
information made accessible from all places and at all times ina 
reasonably efficient manner and with reasonable accuracy. In the rest 
of this work a network is the media for transmitting information. 
Network elements are equipment with one or more network interfaces 
whereby it is possible to exchange information with the network. 
Network elements with multiple interfaces e.g., 
gateways/routers/bridges/repeaters... may be used to connect 
networks. Network related information, referred to as ’network map’ 
in the rest of this paper, should 


1. Show the interconnection between the various network 
elements. This will basically represent the Network as a graph 
where vertices represent objects like gateways/workstations/ 
subnetworks and edges indicate the connections. 


2. Show properties and functions of the various network elements 
and the interconnections. Attributes of vertices will represent 
various properties of the objects e.g., speed, charge, protocol, OS, 
etc. Functions include services offered by a network element. 


3. Contain various name and address information of the networks 
and network elements 


4. Contain information about various administrative and management 
details related to the networks and network elements. 


5. Contain the policy related information, part of which may be 
private while the other part may be made public. 


Using this map the following services may be provided 
1. Configuration management: 
- Display the physical configuration of a network, 
i.e., nodes and their physical interconnections 
- Display the logical configuration of a network, 
i.e., nodes and their logical interconnections. 
2. Route management: 
- Find alternate routes by referring to the physical 
and logical configurations. 


- Generate routing tables considering local policy and 
policy of transit domains 
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—- Check routing tables for routing loops, 
non-optimality, incorrect paths, etc. 


3. Fault management: In case of network failures 
alternatives may be found and used to bypass the 
problem node or link. 


4. Service management: Locate various services and 
servers in the Network. 


5. Optimization: The information available can be used 
to carry out various optimizations, for example cost, 
traffic, response-time, etc. 


6. Provide mappings between the various names and 
addresses of elements 


7. Depict administrative/autonomous domains. 


8. Network Administration and Management: References to 
people responsible for administering and technically 
maintaining a network will be useful. 


Examples of such usages are described in [3], [4]. 
3. The Nature of the Network Map - The X.500 solution 


Implementing and maintaining a detailed map of the network poses a 
serious problem. The scope of the map is global and the network 
itself is expanding. Some of the problems that are peculiar to the 
network map are listed below. 


o The Network configuration is quasi-static. Nodes, 
links and networks are being added,updated and deleted 
someplace or the other. 


o The Network is huge and geographically distributed. 


o The network spans several political and administrative 
areas. The related information is also controlled and 
maintained in a distributed fashion. 


In short, global network configuration information is unwieldy and 
growing continuously. It is impossible to service such information 
in a centralized fashion. There is need for a distributed framework 
which allows users and applications to access information about 
users, services, networks, ... easily and globally. The OSI X.500 
Directory services [5] provides a rich framework to support a 
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globally distributed information service system. The X.500 Directory 
is intended to be a very large and highly distributed database. It is 
structured hierarchically with entries arranged in the form of a tree 
in which each object corresponds to a node or an entry. Information 
is stored about an object as a set of attributes. 


4. The hierarchical model of a network 


For representing networks in the Directory we use the following 
hierarchical model. 


A network is the media for transmitting information with zero or more 
network elements each having at least one network interface on the 
media. The media may be any kind of a line (physical circuit/virtual 
circuit), or a collection of interconnected networks. 


< The postscript version of this document > 
< has a figure here. However, the figure > 
<is too complex to be drawn in simple ASCII.> 


Figure 1: Simple and composite networks and their mapping to the DIT. 


The model allows hierarchy of subnetworks. Network elements with 
multiple interfaces may act as external gateways to the attached 
network and to networks higher up in the hierarchy. Thus, a gateway 
may be the external gateway of several networks which are either 
interconnected or have a hierarchical relationship. 


A network may be simple consisting of zero or more network elements 
or composite consisting of several sub-networks. Examples of simple 
networks are ethernets, optical fiber/copper cables, free space, 


4.1 Network Maps 


Using the above model it is straight forward to draw the topological 
graph of the network where the vertices represent the components of 
the network and edges indicate the connections. For visual 
representation the graph may be translated to a more "physical" 
illustration (figure 1). 


Just as there are several maps of the same geographical domain 
(political, natural...) one can envisage several views of the same 
network and its components. A view (called "image" in the remainder) 
could pertain to a particular protocol suite (IP/OSI/...), an 
administrative domain or purpose. Using images, several abstractions 
of the same object are possible. 
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4.2 Representation in the X.500 Directory 


To represent the various images of networks and its components along 
with the real-image relationship among the various objects we 
introduce the following classes of objects: 


o Communication Object Class (CO): All objects defined 
furtheron in this document belong to this class. 
Common attributes for all communication objects are 
defined in section 6. 


o Physical Communication Object Class (PCO): A subclass 
of CO-class, this class defines common properties for 
all objects representing physical communication objects. 


o Image Communication Object Class (ICO): A subclass of 
CO-class, this class defines common properties for all 
objects representing images of communication objects. 


The above classes sort communication objects into physical or image 
object. As is implied in the nomenclature a physical object will 
have several attributes describing it physical properties - location, 
weight, size, .... etc. An image object will have an Image-of 
attribute. The Image-of attribute will point to a physical object or 
to another image object. 


Using this schema it is possible to represent the case of several 
logical network systems (running different protocol stacks - IP, XNS, 
SNA, OSI, ...) which coexist on the same physical network. 
Information related to different types of networks, no matter what 
the underlying communication protocol is, will reside in the 
Directory in harmony. Also, their interrelation will be represented 
and accessed in a fashion independent of the source/destination 
network, namely, using the OSI X.500 protocol. 


Schemes for physical networks and logical images of physical networks 
are defined in section 6. 


All objects are defined in section 6. 
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Figure 2: Several logical views of the same physical network 
Position in the Directory Information Tree (DIT) 


Information about networks usually will be contained in the DIT as 
subordinate of the organization maintaining the network. The network 
model gets mapped into a tree structure for network elements. There 
is one network object giving general descriptions of the network. 
Subordinates of this network object are node objects for each node 
element present in the network. Node objects hold networkInterface 
objects as subordinates. A network can be physically or logically 


subdivided into several (sub)networks. In this case, a network entry 
will have network objects as subordinates which again build the same 
structure. These entries may be kept as subordinates of 


organizationalUnit entries as well, with pointers from the "root" 
network. 
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This structure holds for physical and logical elements. Physical 
elements are named network, node and networkInterface, and logical 
elements are named networkImage, nodeImage and networkInterfaceImage. 


_root_ 
/ \ 
/ \ 
/ \ 
country \ 
/ \ 
/ organization 
/ / | \ 
/ / | \ 
/ / | \ 
/ / | \ 
/ organizationalUnit* \ 
/ / NAN \ 
/ / O] \ 
/ / \ | Wey 
Person A ERE yee aay 
| 
| | 
Node NodeImage 


NetworkInterface NetworkInterfaceImage 


Legends: * the object may recursively contain objects of 
same class as children 


Figure 3: Part of the Directory Information Tree, 
showing relations of White Pages and network objects 


6. Proposed Schemes 


A physical network comprises of wires and machines. The physical map 
of the network will show the interconnections of these nodes by these 
circuits. 


For each physical network element, one or more images may exist. 
Similarly, an image may be attached to one or more physical objects. 
The types of images can grow along with the requirements. 
Relationship between elements (physical or logical) are expressed by 
attributes or the position in the Directory tree. 
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Problems that are addressed in the schema: 


Avoiding data duplication 

Preserving administrative boundaries/controls. 

Simple representation (minimal number of pointers) 

Security: Though no special emphasis has been placed 

in this work we believe the X.500 access control policies 
policies will provide a reasonable secure framework for security 
and privacy. 


BWwWDN EF 


Problems that are not addressed: 
1. Caching policies, etc.: to be decided locally 
6.1 Communication Object Classes 
The object classes introduced in section 4 are defined as follows: 


CommunicationObject OBJECT CLASS 
SUBCLASS of top 

MAY CONTAIN { 
description :: CaseIgnoreStringSyntax, 

/* can contain any information about the object, 
however, wherever an appropriate attribute 
exists, this should be used first to hold 
information */ 

adminContact :: distinguishedNameSyntax, 

/* points to the person which is responsible for 
the administration of the instance this object 
describes; 

This refers to the instance only in the context 
of the concrete object class */ 
technContact :: distinguishedNameSyntax, 

/* points to the person which is responsible for 
the technical maintenance of the instance this 
object describes; 

This refers to the instance only in the context 
of the concrete object class; 

Availability (e.g. hours of service) is not 
covered by this attribute. */ 


} 


PhysicalCommunicationObject OBJECT CLASS 
SUBCLASS of CommunicationObject 
MAY CONTAIN{ 
owner :: distinguishedNameSyntax, 
/* refers to organization or person owning the 
physical element; 
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Note that more detailed information (like lease, 


rental, etc.) can be covered in a specific image 
(ownerImage) of this element */ 
localityName :: CaseIgnoreStringSyntax 


/* where the object is located; 
can be used freely to "spot" a network element, 
e.g. state/city/street/building/floor/room/ 
desk/... */ 
ICO :: distinguishedNameSyntax 
/* points to image object the physical object 
is related to; 
might have several values if physical object is 
used for several applications at the same time */ 


} 


ImageCommunicationObject OBJECT CLASS 
SUBCLASS of CommunicationObject 
MAY CONTAIN{ 
type :: caseIgnoreStringSyntax, 
/* expresses the view this object refers to, e.g. 
view of provider/user/IP/OSI/...; 
Note that this information can be covered by 
the object class in some cases 
(e.g. ipNetworkImage gives the IP view) */ 
imageOf :: distinguishedNameSyntax, 
/* points to physical/image object the image 
is related to; 
might have several values if view applies to 
several physical objects at the same time */ 


} 
6.2 Physical elements 


The following objects describe network elements without saying 
anything about their usage. All objects inherit properties of the 
PhysicalCommunicationObject class. 


6.2.1 Network 


The network object supplies general descriptions which are common for 
a set of nodes and circuits comprising one network. This includes 
information about the type of circuits (medium, broadcast or point- 
to- point, etc.) and properties (speed etc.). 


network OBJECT CLASS 

SUBCLASS of PhysicalCommunicationObject 
MUST CONTAIN { 

networkName :: caseIgnoreStringSyntax } 
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MAY CONTAIN { 
externalGateway distinguishedNameSyntax, 


/* points to one or more nodes that connect 
this network to neighbor networks; 
whether a node actually is used as gateway 
for one or the other protocol, is defined 
in a related networkImageObject */ 
nwType :: caseIgnoreStringSyntax, 

/* type of this network; 
either "composite" (if consisting of subnetworks) 
or type of a line: 
bus, ring, star, mesh, point-to-point */ 

media :: caseIgnoreStringSyntax, 

/* if network is not composite, 
describes physical media: 
copper, fiber optic, etc. */ 


speed :: numericStringSyntax, 
/* nominal bandwidth, e.g. 64 kbps */ 
traffic :: numericStringSyntax 
/* (average) use in percent of nominal bandwidth 
*/ 


[ this needs more specification later ] 
configurationDate uTCTimeSyntax, 
/* date when network was configured in current 
shape */ 
configurationHistory caselIgnoreStringSyntax 
/* list of configuration changes, like: 
added/removed nodes, lines */ 


} 


6.2.2 Node 


The node object describes any kind of device that is part of the 


network, such as simple nodes, printer, bridges. 


node OBJECT CLASS 
SUBCLASS of PhysicalCommunicationObject 


MUST CONTAIN { 
nodeName :: caseIgnoreStringSyntax } 
MAY CONTAIN { 


machineType 
/* e.g. main frame, work station, 


might include manufacturer */ 


OS :: caseIgnoreStringSyntax, 
/* e.g. VM, UNIX, DOS; might include release */ 


caselIgnoreStringSyntax, 
PC, printer; 
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6.2.3 NetworkInterface 


Each node object will have one or more networkInterface objects as 
subordinates. NetworkInterface objects provide information about 
interfaces of the node and connectivity. 


networkInterface OBJECT CLASS 
SUBCLASS of PhysicalCommunicationObject 
MUST CONTAIN { 
networkInterfaceName :: caseIgnoreStringSyntax 
/* It is suggested that the networkInterface 
name is derived from the name of the logical 
device this networkInterface represents for 
the operating system, e.g. leO, COM1 */ 


} 
MAY CONTAIN { 

networkInterfaceAddress :: caseIgnoreStringSyntax, 

/* this should contain a protocol-independent 

interface address, e.g. Ethernet board number */ 

connectedNetwork :: distinguishedNameSyntax, 

/* pointer to object of network which this networkInterface is 

connected to */ 


} 
6.3 Logical Elements 


An abstract view of a physical element is called image in this 
document. The word image gets appended to the object type, leading 
to the new objects networkImage, nodeImage and networkInterfaceImage. 
Images will either build Directory trees of themselves or be stored 
as part of the physical network tree (see section 5). 


Image objects inherit properties of the ImageCommunicationObject 
class. 


Each image object has specific attributes which vary depending on the 
point of view (IP, OSI, ...). Also, the user and provider of an image 
will view an object differently; further a user of an object may also 
be providing the services of the same object to another user. 


Therefore, in the following a complete and general list of attributes 
cannot be given. We recommend to define subclasses of Image classes 
for each logical view. These subclasses inherit all attributes 
defined with the object classes below and add more specific 
attributes. Examples for an IP-view are given in [1]. 
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6.3.1 Network 


There may be several network images for one and the same physical 
network: one for each protocol, application, etc. 


networkImage OBJECT CLASS 
SUBCLASS of ImageCommunicationObject 
MAY CONTAIN { 
externalGateway :: distinguishedNameSyntax, 
/* points to one or more nodes that act 
as gateway for the protocol application 
this images refers to */ 
speed :: numericStringSyntax, 
/* nominal bandwidth for the channel dedicated 
to this protocol or application , 
e.g. 64 kbps */ 


traffic :: numericStringSyntax, 
/* (average) use in percent of nominal bandwidth 
[this needs more specification later ] */ 
charge :: numericStringSyntax 


/* amount of money that has to be paid to 
service provider for usage; 
[it is felt that this needs further definition: 


e.g. monetary unit / time unit, monetary unit / 
data unit ] */ 


} 


6.3.2 Node 


Name and functionality within the network might vary for a node from 
protocol to protocol considered. In particular, a node might act as 
gateway for one protocol but not for the other. Routing policy is 
stored in the case of policy gateways. 


nodeImage OBJECT CLASS 
SUBCLASS of ImageCommunicationObject 
/* no attributes common for all nodeImages have been 
defined yet */ 


6.3.3 NetworkInterface 


As with physical nodes, nodeImages have networkInterfaces 
(networkInterfaceImages) which describe connectivity to other network 
elements. NetworkInterfaceImages are only given if the protocol is 
establishing connections via this networkInterface. 


networkInterfaceImage OBJECT CLASS 
SUBCLASS of ImageCommunicationObject 
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MAY CONTAIN { 
networkInterfaceAddress :: caseIgnoreStringSyntax, 
/* the networkInterface address in the image 
context, e.g. IP number, NSAP */ 
connectedNetwork :: distinguishedNameSyntax 
/* pointer to networkImageObject that describes 
the network this networkInterface is attached 
to in terms of the protocol or application the 
image indicates */ 


} 
7. Security Considerations 
Security issues are not discussed in this memo. 
8. Authors’ Addresses 


Glenn Mansfield 

AIC Systems Laboratory 
6-6-3 Minami Yoshinari 
Aoba-ku, Sendai 989-32 
Japan 


Phone: +81 22 279-3310 
EMail: glenn@aic.co.jp 


Thomas Johannsen 

Dresden University of Technology 
Institute of 

Communication Technology 

D-01062 Dresden 

Germany 


Phone: +49 351 463-4621 
EMail: Thomas.Johannsen@ifn.et.tu-dresden.de 


Mark Knopper 

Merit Network, Inc. 
1071 Beal Avenue 
Ann Arbor, MI 48109 


EMail: mak@merit.edu 


Mansfield, Johannsen & Knopper [Page 14] 


RFC 1609 Charting Networks in the X.500 Directory March 1994 


9. References 


[1] Harrenstein, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC 
954, SRI, October 1985. 


[2] Mockapetris, P., "Domain Names - Implementation and 
Specification", STD 13, RFC 1035, USC/Information Sciences 
Institute, November 1987. 


[3] Johannsen, T., Mansfield, G., Kosters, M., and S. Sataluri, 
"Representing IP information in the X.500 Directory", RFC 1609, 
Dresden University, AIC Systems Laboratory, Network 
Solutions, Inc., AT&T Bell Laboratories, March 1994. 


[4] Johannsen, T., and G. Mansfield, "The Soft Pages Project", OSI-DS 
WG document, OSI-DS-39, Dresden University, AIC Systems 
Laboratory, February 1993. 


[5] CCITT Blue Book, "Data Communication Networks: Directory", 
Recommendations X.500-X.521, December 1988. 


Mansfield, Johannsen & Knopper [Page 15] 


